Achieving ISO 9001 Certification for an XP Company

It is generally assumed that certification such as ISO 9001 is incompatible with Agile Development Methods, particularly eXtreme Programming. However it is possible to achieve certification in a manner that is compatible with XP and does not reduce agility. The key to this is making the documentation, process monitoring and audit trail required for certification a natural output of the development process rather than an artificial product created purely to satisfy those requirements. This paper describes the successful certification of an XP company. Introduction The company described in this paper, Workshare [1], adopted XP in February 2001. The company produces document content management and collaboration software. Currently five products have been released, built around a common code base. The development environment differs from that of many XP shops in a number of ways including a reliance on C++ and COM, a high GUI content within its products and a large development team. During the past two years the XP process has been tailored to manage this large team. This has resulted in the concept of the “virtual white board” which in turn became central to achieving ISO 9001:2000 TickIT [2, 3] certification. For brevity this is subsequently referred to as ISO 9001 The company began preparing for certification in March 2002 and was recommended for certification following a successful audit in February 2003. A key feature of achieving this was that the documentation, process monitoring and audit trail required for certification was already place within the company as a result of the earlier efforts required to manage a large engineering team producing multiple products. We believe that we are amongst the first, if not the first, company using XP for all its development to gain ISO 9001 certification. ISO 9001 requirements ISO 9001 requires companies to set up quality management systems to “monitor, measure and continually improve their business processes” [3]. Guidance for applying ISO 9001 requirements to the software industry are contained the TickIT guide [3]. TickIT arose from the recognition that the process for software development and maintenance is different than that of most other industrial products. The desire to devise an ISO registration scheme for software resulted in TickIT being formulated by IT professionals in the UK. The objectives of TickIT are as follows: To ensure the ISO standard is applied appropriately to software To ensure consistency of certification with the IT Industry To enable mutual recognition of registration across the IT industry. The TickIT guide tends to state more of how to implement an ISO 9001 system, while the standard states what must be done. In practice certification requires a company to formulate a quality policy and manual, institute a quality management system and maintain sufficient records to prove that the processes within the company are quality driven, measured and reviewed, and that there is a continual improvement in those processes. Some common misconceptions There are a number of misconceptions concerning ISO 9001 and the XP process. Firstly it is commonly assumed that gaining certification is merely a matter of following any documented process; secondly many in the XP community believe the level of documentation required for certification contradicts core XP principles and is inherently non-agile; thirdly it is not understood that certification is for the entire company and not just for the development process within that company. The first misconception is due to the fact that earlier versions of the ISO standard did emphasise the documentation of procedures over the quality of those procedures. However the current standard is based on quality within a process: “ISO 9001:2000 is intensively process-orientated and requires an organisation to identify, manage and continually improve all processes” [3, page F1]. This emphasis on process leads to the second misconception that certification standards such as ISO are incompatible with Agile Methods such as XP, either because the standard specifies a process that can not be followed using XP or because proving that the process is being monitored and improved places such an overhead on that process that it ceases to be agile. Although ISO 9001 “does not define a particular life cycle model” [3, page F2] it does reference the model described in ISO/IEC 12207 [4], which is essentially a high level description of the old waterfall process in its V-model form. However other methodologies can map their processes to this reference model. This has already been done for DSDM, the most process heavy of the Agile methodologies [5]. The key factor is not the process but the ability to demonstrate that this process can meet the ISO 9001 objectives of managing and improving quality. There is nothing explicit or implicit in XP that precludes this. Indeed it can be agued that the change in emphasis within the ISO standard from documentation to process favours those methods such as XP that have a clear set of practices. However in order to maintain agility it is essential that demonstrating quality and improvement in the process relies on natural outputs from XP rather than on artefacts created purely for the certification audit. Finally although this paper describes ISO certification as it relates to XP it is important to realise that certification applies to the entire company and is based on all the procedures within that company not just to the software development process. So for instance XP starts with a customer story but certification would also depend on the quality of processes leading to the inception of that story, not solely on the quality of the implementation of that story. For Workshare, being a commercial software house, this involves all the processes involved in managing external customer issues and feature requests as well as the formulation of high-level business strategy. Managing a large team Since Workshare adopted XP we have attempted to do things “by the book” and not deviate from any of the core practices. However because of the size of the team (30 programmers, 11 customers / product managers, 11 QA in our London office with a smaller team in South Africa) and the multiple products we have expanded our integration, testing and management procedures. As in a standard XP shop developers run all the unit tests on their machine before copying changes files to an integration machine. The tests are run again before checking into the source repository, the results of which are also recorded in a central database. The files changed for each story are recorded, initially manually on integration sheets but now also in a central database. Builds are produced twice a day on separate machines and a second set of tests is run on the output. These functional tests consist of tests that take too long to run during integration or that involve gross or round trip behaviour. QA run their own sets of tests; acceptance tests are run when the story is first integrated, acceptance and regression tests are run on the output of the build machines. We found a collection of story cards did not give sufficient information to manage the engineering process. Our solution was Bluesky, a virtual white board containing story cards. This is an electronic copy of all the information contained in the story cards together with additional information such as; How far each story and task has progressed, Initial and subsequent estimates for the story and tasks, The product and build containing the integrated story, Confirmation that the customer has seen the completed story, Results from QA, both of the initial integration and from the final build. The data contained in the Bluesky and auxiliary databases, together with the integration sheets, provided the information required by the ISO 9001 auditor to verify our compliance with the processes detailed in the engineering quality manual. Bluesky – a virtual white board Top-level view summarising progress of each story. dividual story card, including QA test results, in electronic format ask list contained at the end of story card In